Web developers often add new features to a web application after the web application has already been deployed to actual users. These new features may interfere with older features in terms of user experience. For example, displaying a “register for our email list” button alongside a “sign up now” button may cause user confusion as to which button a user should click in order to create a new user account.
User confusion can cause significant problems once a new feature is deployed. For example, user sign-up rate could drop based on the addition of the email list button, which is unrelated to creating a new user account. Furthermore, the cause of the drop in sign-up rate may be buried three or four web pages deep in the sequence of user interface interactions required to create a new user account. Thus, the problem remains hidden until an actual user or a quality assurance (QA) specialist identifies the problem.
Traditional testing tools may not catch these issues because the web application still technically works as intended. For example, a testing tool for checking the “create new user” task may not throw an error because the testing tool may only simulate whether the features, once activated, act properly.
Once an error is found, documentation technologies allow an end user or tester to screencast or video tape the steps taken in order to reproduce an error. Some of these technologies annotate the steps taken that caused the error. Then a troubleshooting specialist may compare the steps the user performed with steps the user should have performed in order to rectify the error.
Unfortunately, there is no current technology to review expected user behavior each time a feature is added to a complex web application for QA purposes. The current practice of incremental deployment of features in a web application causes user experience (UX) issues to arise sporadically, and the QA specialist must explore the new features within the web application in hopes of spotting an error.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.